Method and system for using dynamic content types

ABSTRACT

In general, embodiments of the technology relate to a method and system for implementing a dynamic content type (DCT) in a content management system. More specifically, embodiments of the technology relate to using a DCT in order to change and/or extend the functionality of the content management system.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This is a continuation of, and claims a benefit of priority under 35U.S.C. 120 of the filing date of, U.S. patent application Ser. No.14/755,858, filed Jun. 30, 2015, entitled “METHOD AND SYSTEM FOR USINGDYNAMIC CONTENT TYPES,” which is fully incorporated by reference herein.

BACKGROUND

Significant amounts of content is stored in content repositories. Theaccess and manipulation of this content is typically limited topre-defined constructs and/or methods. When attempts are made to modifythe pre-defined constructs and/or methods, such attempts requiresignificant resources and time to implement.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 shows an exemplary system in accordance with one or moreembodiments of the technology.

FIG. 2 shows an exemplary object in accordance with one or moreembodiments of the technology.

FIG. 3 shows an exemplary dynamic content type (DCT) rule specificationin accordance with one or more embodiments of the technology.

FIG. 4 shows a method for configuring a system to use dynamic contenttypes in accordance with one or more embodiments of the technology.

FIG. 5 shows a method for servicing requests in accordance with one ormore embodiments of the technology.

FIG. 6 shows a computing system in accordance with one or moreembodiments of the technology.

DETAILED DESCRIPTION

Specific embodiments of the technology will now be described in detailwith reference to the accompanying figures. In the following detaileddescription of embodiments of the technology, numerous specific detailsare set forth in order to provide a more thorough understanding of thetechnology. However, it will be apparent to one of ordinary skill in theart that the technology may be practiced without these specific details.In other instances, well-known features have not been described indetail to avoid unnecessarily complicating the description.

In the following description of FIGS. 1-6, any component described withregard to a figure, in various embodiments of the technology, may beequivalent to one or more like-named components described with regard toany other figure. For brevity, descriptions of these components will notbe repeated with regard to each figure. Thus, each and every embodimentof the components of each figure is incorporated by reference andassumed to be optionally present within every other figure having one ormore like-named components. Additionally, in accordance with variousembodiments of the technology, any description of the components of afigure is to be interpreted as an optional embodiment, which may beimplemented in addition to, in conjunction with, or in place of theembodiments described with regard to a corresponding like-namedcomponent in any other figure.

In general, embodiments of the technology relate to a method and systemfor implementing a dynamic content type (DCT) in a content managementsystem. More specifically, embodiments of the technology relate to usinga DCT in order to change and/or extend the functionality of the contentmanagement system such that the manner in which actions may be performedon objects and the results of performing actions on the objects may varybased on the context of the request that specified the action. Saidanother way, in one or more embodiments of the technology, a firstrequest to perform an action on an object and a second request toperform the same action on the same object may generate differentresults based on the context of the first request and the secondrequest.

FIG. 1 shows an exemplary system in accordance with one or moreembodiments of the technology. The system includes one or more clientsystems (100A, 100N), a content management server (102), and one or morecontent repositories (108A, 108M). The aforementioned components maycommunicate with each other using any known or later discoveredcommunication protocol. Further, the aforementioned components maycommunicate using any combination of wired and/or wireless connectionsand wired and/or wireless networks. Each of the aforementionedcomponents is described below.

In one embodiment of the technology, a client system corresponds to anycomputing system (see e.g., FIG. 6) that includes functionality to issuerequests to the content management server (102) and to receive acorresponding response(s) from the content management server after therequest has been serviced.

In one embodiment of the technology, each client system may be referredto as a platform, where the platform includes the combination ofhardware and software (including the operating system, virtual machines,etc. but excluding applications) executing on the hardware. Each clientsystem may also include one or more applications, where the applicationsare executing on the platform. In one embodiment of the technology, eachplatform and/or application may be characterized as public (e.g., theplatform is operating on a public computing network or is a publiclyaccessible computing system) or private (e.g., the platform is operatingon a private computing network (e.g., an internal company network) or isa computing system that is provisioned by a company (or another legalentity) for use by the company's employee). Additionally, oralternatively, the platform and/or application may also be characterizedbased on the level of security measures (e.g., encryption, multi-factorauthentication, secure communication protocols, etc.) implemented in theplatform and/or application (e.g., a rating scale of 1-5 may be usedwhere 1 is unsecure and 5 is the highest level of security). Eachplatform and/or application may be characterized using othercharacterization schemes without departing from the technology. Further,each platform and/or application may be characterized using acombination of characterization schemes (e.g., a platform may becharacterized as private, level 3 security).

Continuing with the discussion of FIG. 1, the content management serverincludes functionality to perform the method shown in FIG. 4. Further,the content management server may include functionality to receiverequests from one or more client's systems and to service such requestsusing the DCT rules engine (104) and the object model (106). The contentmanagement server may also include functionality to perform variousactions (e.g., read, write, delete, modify, etc.) on the objects storedin the content repositories when servicing requests from the clientsystems (see e.g., FIG. 5). In one embodiment of the technology, the DCTrules engine (104) includes functionality to identify the appropriateDCT rule to use to service a request and, at least in part, service therequest using the identified DCT rule (see e.g., FIG. 5). In oneembodiment of the technology, the object model (106) specifies theobject types that are supported by the content management service andhow the management service is to interact with such objects (based ontheir object type). With respect to the DCT, the object model mayspecify that the content management service supports the DCT and mayalso specify that the processing of objects with an object type of DCTis determined, at least in part, by the DCT engine.

In one embodiment of the technology, the DCT engine may implement one ormore DCT rules. The DCT engine (or, more generally, the contentmanagement service) may include functionality to store and manage theDCT rules. Additional detail about the DCT rules is provided in FIG. 3.

In one embodiment of the technology, the content management serviceincludes functionality to determine, obtain, and/or store thecharacterization of the platforms and/or applications with which it isinteracting. Such information may then be used to perform at least thefunctionality described in FIG. 5.

The content management server may be implemented using one or morecomputing systems (see e.g., FIG. 6). Additional detail about theoperation of the content management server is provided in FIGS. 4 and 5.

In one embodiment of the technology, each content repository (108A,108M) includes persistent storage (e.g., solid state storage, magneticstorage, optical storage, any other type of persistent storage or anycombination thereof) in which objects (see e.g., FIG. 2) are stored.

Continuing with the discussion of the content repositories, each of thecontent repositories may store objects using any known or subsequentlydiscovered mechanism. The following describes various examples of themechanisms that may be used to store objects. The examples are notintended to limit the technology. In a first example, the contentrepository (108A, 108M) may be a set of magnetic hard disks. In a secondexample, the content repository (108A, 108M) may be implemented using acomputer cluster that is executing a distributed file system. In a thirdexample, the content repository (108A, 108M) may be implemented using anetwork file server and one or more block-storage devices (i.e., as aStorage Area Network).

The technology is not limited to the architecture of the system shown inFIG. 1.

FIG. 2 shows an exemplary object in accordance with one or moreembodiments of the technology. The object (200) corresponds to acombination of content (208) and the metadata (206) associated with thecontent. The metadata (206) may include the object type (204) as well asany other metadata associated with the object. Examples of metadata mayinclude, but are not limited to, author, content name, creation time,creation date, size of object, modification time, modification date,object format (i.e., the format of the content (208), e.g., portabledocument format (PDF), MPEG-4, .txt., etc.). Wth respect to the content,the content may correspond to any type of data that may be stored in thecontent repository. Examples of content may include, but are not limitedto, text files, audio files, image files, and/or audio-visual files.

In one embodiment of the technology, each object (200) may be identifiedusing an object ID (202). The object ID uniquely identifies the objectin the content repository. The object ID may be any combination ofnumbers, letters, and symbols.

In one embodiment of the technology, the metadata and content associatedwith a given object may be stored in a single location. Alternatively,the metadata associated with an object may be stored in a first locationand the content associated with a given object may be stored in a secondlocation, where the first and second locations may be in the same ordifferent content repositories.

FIG. 3 shows an exemplary dynamic content type (DCT) rule in accordancewith one or more embodiments of the technology. Each DCT rule (300)includes a context definition (302) and may include one or more of thefollowing: metadata visibility rules (304), content visibility rules(306), and permitted actions (308). Each of the components of the DCTrule is described below.

In one embodiment of the technology, the context definition (302)specifies when the DCT rule should be applied to service a request. Saidanother way, the context definition (302) specifies the context(associated with the request) for which the DCT rule applies. In oneembodiment of the technology, the context definition may be definedusing one or more regular expressions.

The context definition may be specified at any level of granularity. Forexample, the context definition may specify one or more of thefollowing: (i) the object, e.g., using the object ID or using anexpression (e.g., a regular expression) that may be used to identify theobject (e.g., if content in the object is an audio-visual file); (ii)the action (or set of actions); (iii) a characterization associated withthe source platform (i.e., the platform from which a request was issued(see e.g., FIG. 5, step 500)); (iv) a characterization associated withthe source application (i.e., the application from which a request wasissued (see e.g., FIG. 5, step 500)); (v) the user that issued therequest; (vi) a characterization associated with a target platform(i.e., the platform on which the object will be viewed if the request issuccessfully serviced); (vii) source content repository (i.e., thecontent repository in which the object is currently stored); and (viii)target content repository (i.e., the content repository in which theobject will be stored if the request is successfully serviced). Thecontext definition may specify additional and/or other informationwithout departing from the technology.

Continuing with the discussion of FIG. 3, the DCT rule may includemetadata visibility rules (304). In one embodiment of the technology,the DCT rule may specify which metadata may be visible to the platformand/or application when the request is successfully serviced. Forexample, the metadata visibility rule may specify that when a givenrequest is serviced based on the DCT rule only the content name andcontent format type may be visible.

Continuing with the discussion of FIG. 3, the DCT rule may includecontent visibility rules (306). In one embodiment of the technology, theDCT rule may specify which content may be visible to the platform and/orapplication when the request is successfully serviced. For example, thecontent visibility rule may specify that when a given request isserviced based on the DCT rule that specific portions (e.g., certainpages, certain words, certain sentences that include certain words,etc.) of the content are to be redacted.

Continuing with the discussion of FIG. 3, the DCT rule may includepermitted actions (308). In one embodiment of the technology, the DCTrule may specify: (i) actions that may be performed on an object in thecontext (as defined by the context definition) and (ii) actions that thesource application, source platform, or target platform may perform onan object that is retrieved in response to a request. For example, thepermitted actions may specify that for the context (as defined by thecontext definition), a request to view the content in the object ispermitted but a request to store the content in a different contentrepository is not permitted.

In another example, the permitted actions may specify that if an objectis obtained in response to the servicing of a request (see FIG. 5), thecontent of the object may be viewed but not printed. In this example,the information about the permitted (or not permitted) actions may besent to the source platform or source application (as defined above).Upon receipt of the above information, the source platform or sourceapplication may disable any features in the application that wouldenable a user to initiate actions that are not permitted. In the instantexample, the source application may disable the printing functionalityfor the content associated with the retrieved object.

The DCT rule may specify additional or other information withoutdeparting from the technology.

FIGS. 4 and 5 show flowcharts in accordance with one or more embodimentsof the technology. While the various steps in the flowcharts arepresented and described sequentially, one of ordinary skill willappreciate that some or all of these steps may be executed in differentorders, may be combined or omitted, and some or all of the steps may beexecuted in parallel.

Turning to FIG. 4, FIG. 4 shows a method for configuring a system to usedynamic content types in accordance with one or more embodiments of thetechnology.

In step 400, a dynamic content type (DCT) is created within the objectmodel. Once the DCT has been added to the object model, objects withinthe content repositories may be associated with the DCT.

While step 400 includes the creation of a DCT within the object model,the creation of the DCT does not require an immediate specification ofany DCT rules. Rather, the DCT rules may be created at any time afterthe DCT is created within the object model. For example, some DCT rulesmay be specified at the time the DCT is created in the object modelwhile other DCT rules may be specified after the content managementsystem has been deployed (i.e., at run time). Further, DCT rules may beadded, modified, and deleted at any point after the content managementsystem has been deployed. Accordingly, following step 400, the processmay proceed to step 402 or to step 406.

In step 402, one or more DCT rules (see FIG. 3) are obtained by thecontent management system. In one embodiment of the technology, the DCTrules may be obtained from one or more client systems, from a 3^(rd)party (not shown), from a developer of the content management system, orfrom any other entity. In step 404, the DCT rules obtained in step 402are provided to the DCT rules engine. Following step 404, the processmay end or may proceed to step 406.

In step 406, the object type of one or more objects is set to DCT. Inone embodiment of the technology, the object type for a given object maybe set to DCT at the time the object is initially stored in a contentrepository. In one embodiment of the technology, the object type for agiven object may be set to an object type that is not DCT when theobject is initially stored in a content repository. Then at some laterpoint in time the object type of the object may be changed to DCT.

FIG. 5 shows a method for servicing requests in accordance with one ormore embodiments of the technology.

In step 500, a request is received by the content management servicefrom a requesting entity (e.g., a client system). In one embodiment ofthe technology, the request includes an object ID and an action(s) to beperformed on (or with) the object (or a portion thereof) associated withthe object ID. The request may include additional information (e.g.,parameters associated with the action) without departing from thetechnology. The action may correspond to any action that may beperformed on any portion of the object (i.e., on the content ormetadata, see e.g., FIG. 2). Examples of actions may include, but arenot limited to, read, write, modify, delete, and move. In one embodimentof the technology, the request may include specify a set of objectsusing, e.g., object IDs or a regular expression.

In the event that the request specifies multiple objects and/or multipleactions, steps 502-512 may be performed for every <object ID, action>pair.

In step 502, the object type for the object (i.e., the objectcorresponding to the object ID) is obtained. In one embodiment of thetechnology, step 502 may include querying the content repository tolocate the object corresponding to the object ID and then obtaining themetadata (including the object type) from the content repository.

In step 504, a determination is made about whether the object type forthe object is DCT. If the object type for the object is DCT, then theprocess proceeds to step 508; otherwise, the process proceeds to step506.

In step 506, a request which specifies an object, which has an objecttype that is not DCT, is processed by the content management system inaccordance with the object model. Said another way, the request isserviced without invoking the DCT rules engine or any of the DCT rules.The result(s) generated by servicing the request is sent to therequesting entity (i.e., the entity that issued the request in step500).

Returning to step 504, if the object type for the object is DCT, thenthe process proceeds to step 508. In step 508, the context associatedwith the request is determined (or otherwise obtained). The contextassociated with the request may include some or all of the followinginformation: (i) object ID, (ii) source platform, (iii) sourceapplication, (iv) user information (i.e., which user initiated therequest), (v) action being requested to be performed on the object, (vi)possible target platform if the request is successfully serviced, (vii)source content repository, (viii) possible target content repository ifthe request is successfully serviced; and (ix) object content format.The context may include different or additional information withoutdeparting from the technology. The context for the request may bedetermined using any know or later discovered mechanism.

In step 510, a DCT rule to be used to service the request is identified.In one embodiment of the technology, the DCT rule is identified bydetermining all DCT rules that have a context definition that matchesthe context determined in step 508. The most specific DCT rule, i.e.,the DCT rule that includes the most granular context definition, isselected from the set of matching DCT rules as the DCT rule to be usedto service the request. For example, consider a scenario in which DCTrule 1 includes a context definition that specifies the action and thesource platform and DCT rule 2 that includes a context definition thatspecifies the object content format, the action, and the sourceplatform. Further, assume that the context definitions in both DCT rule1 and DCT rule 2 match the context associated with the request. In thisexample, DCT rule 2 would be selected to be used in servicing therequest as DCT rule 2 is more specific than DCT rule 1.

In one embodiment of the technology, if there are no DCT rules thatinclude context definitions that match the context determined in step508, then a default DCT rule may be used to service the request.

In step 512, the request is serviced using the DCT rule identified instep 510. The result(s) of service the request is then sent to therequesting entity. In one embodiment of the technology, servicing therequest may include: (i) determining whether the action in the requestis permitted to be performed on the object based on the permitted actionportion of the identified DCT rule; (ii) if the action can be performedon the object, then the action is performed on the object in accordancewith any content visibility rules and metadata visibility rulesspecified in the DCT rule. For example, if the action is a view actionand certain portions of the metadata of the object are not to be shownto the requesting entity (as specified in the metadata visibility rules)and certain portions of the content of the object are to be redacted (asspecified in the content visibility rules), then the metadata andcontent for the object are obtained and modified prior to being providedto the requesting entity such that the requesting entity only is able toview the modified metadata and the modified content.

In one embodiment of the technology, while the DCT rule may require thatthe metadata and/or content is modified prior to it being provided tothe requesting entity, the actual metadata and content may not bemodified; rather, a copy of the metadata and/or content to be modifiedis created and the copy of the metadata and/or content is modified (perthe DCT rule).

In one embodiment of the technology, the servicing of the request instep 512 may result additional objects being obtained (i.e., an objectthat is not identified in the request obtained in step 500). In suchcases, any of the additional objects that are of object type DCT may beprocessed in accordance with FIG. 5 or may be processed using the sameDCT rules as determined in step 510. Further, any of the additionalobjects that are not of object type DCT may be processed using the sameDCT rules as determined in step 510.

The following section describes examples in accordance with one or moreembodiments of the technology. The examples are not intended to limitthe scope of the technology.

EXAMPLE 1

Consider a scenario in which an object is stored in a first contentrepository that is categorized as “classified”, where the object has anobject type of DCT. At some point in time after the object has beenstored in the first content repository, the content management servicereceives a request to move the object to a second content repository.Upon receipt of the request, the content management service determinesthat the object that is the subject of the request has an object type ofDCT. Based on this determination, the content management service obtainsthe context for the request. In this example, the context of the requestincludes: (i) object ID; (ii) an action (i.e., a move action); (iii) asource content repository (i.e., the first content repository); and (iv)a possible target content repository (i.e., the second contentrepository) (which is determined based on the move action).

The DCT rules engine subsequently identifies DCT rule 1 based on theaforementioned context matching the content definition in the DCT rule.In this example, DCT rule 1 specifies: (i) if the target contentrepository is categorized as “classified” or “top secret” then theobject may be moved to the target content repository without anymodifications; and (ii) if the target content repository is notcategorized as “classified” or “top secret” then various portions of thecontent (as specified in the DCT rule) are redacted and all metadataexcept the content format and the content name is removed from themetadata.

In the instant example, the second content repository is categorized as“unclassified.” Accordingly, the metadata and content of the object aremodified to obtain modified metadata and modified content. The modifiedmetadata and modified content are then stored in a new object in thesecond content repository.

EXAMPLE 2

Consider a scenario in which Bob is working on a company issued laptopon the company's private network. As part of this work, the Bob issues arequest to view the metadata and content associated with an object,where the content in the object corresponds to a software designdocument for a new product.

Upon receipt of the request, the content management service determinesthat the object that is the subject of the request has an object type ofDCT. Based on this determination, the content management service obtainsthe context for the request. In this example, the context of the requestincludes: (i) object ID, (ii) an action (i.e., a view action); (iii)Bob's assigned role 1; and (iv) source platform (i.e., company computerissuing request via company's private network).

The DCT rules engine subsequently identified DCT rule 2 based on theaforementioned context matching the content definition in the DCT rule.In this example, DCT rule 2 specifies: (i) when the source platform iscategorized as “private” then users with role 1 (i.e., senior engineer)may view and print an un-redacted version of the content and all themetadata; (ii) when the source platform is categorized as “private” thenusers with role 2 (i.e., sales team) may view but not print or email anun-redacted version of the content and all the metadata; and (iii) whenthe source platform is categorized as “public” then users with role 1and 2 may view a redacted version of the content and only the contentname (i.e., they cannot view any other portion of the metadata).

In the instant example, Bob's request is serviced in response to DT Rule2 (i) because Bob is at work using a work computer, the source platformcharacterized as “private”. Accordingly, Bob may view an un-redactedcopy of the content and metadata. However, if Bob were to make the samerequest using either his work computer at home via a public network orusing his personal computer at work, Bob's request would be serviced inaccordance with DCT rule 2 (iii) because in the source platform would becharacterized as “public.”

Embodiments of the technology may be implemented on a computing system.Any combination of mobile, desktop, server, embedded, or other types ofhardware may be used. For example, as shown in FIG. 6, the computingsystem (600) may include one or more computer processor(s) (602),associated memory (604) (e.g., random access memory (RAM), cache memory,flash memory, etc.), one or more storage device(s) (606) (e.g., a harddisk, an optical drive such as a compact disk (CD) drive or digitalversatile disk (DVD) drive, a flash memory stick, etc.), and numerousother elements and functionalities. The computer processor(s) (602) maybe an integrated circuit for processing instructions. For example, thecomputer processor(s) may be one or more cores, or micro-cores of aprocessor. The computing system (600) may also include one or more inputdevice(s) (610), such as a touchscreen, keyboard, mouse, microphone,touchpad, electronic pen, or any other type of input device. Further,the computing system (600) may include one or more output device(s)(608), such as a screen (e.g., a liquid crystal display (LCD), a plasmadisplay, touchscreen, cathode ray tube (CRT) monitor, projector, orother display device), a printer, external storage, or any other outputdevice. One or more of the output device(s) may be the same or differentfrom the input device(s). The computing system (600) may be connected toa network (612) (e.g., a local area network (LAN), a wide area network(WAN) such as the Internet, mobile network, or any other type ofnetwork) via a network interface connection (not shown). The input andoutput device(s) may be locally or remotely (e.g., via the network(612)) connected to the computer processor(s) (602), memory (604), andstorage device(s) (606). Many different types of computing systemsexist, and the aforementioned input and output device(s) may take otherforms.

Software instructions in the form of computer readable program code toperform embodiments of the technology may be stored, in whole or inpart, temporarily or permanently, on a non-transitory computer readablemedium such as a CD, DVD, storage device, a diskette, a tape, flashmemory, physical memory, or any other computer readable storage medium.Specifically, the software instructions may correspond to computerreadable program code, that when executed by a processor(s), isconfigured to perform embodiments of the technology.

Further, one or more elements of the aforementioned computing system(600) may be located at a remote location and connected to the otherelements over a network (612). Further, embodiments of the technologymay be implemented on a distributed system having a plurality of nodes,where each portion of the technology may be located on a different nodewithin the distributed system. In one embodiment of the technology, thenode corresponds to a distinct computing device. Alternatively, the nodemay correspond to a computer processor with associated physical memory.The node may alternatively correspond to a computer processor ormicro-core of a computer processor with shared memory and/or resources.

While the technology has been described with respect to a limited numberof embodiments, those skilled in the art, having benefit of thisdisclosure, will appreciate that other embodiments can be devised whichdo not depart from the scope of the technology as disclosed herein.Accordingly, the scope of the technology should be limited only by theattached claims.

1. A method for servicing requests, the method comprising: receiving,from a first requesting entity, a first request to perform an action onan object; making a first determination that an object type of theobject is dynamic content type (DCT); based on the first determination,obtaining a context for the first request; identifying a DCT rule basedon the context; and serving the first request using the DCT rule.
 2. Themethod of claim 1, further comprising: receiving, from a secondrequesting entity, a second request to perform the action on the object;making a second determination that the object type of the object is DCT;based on the second determination, obtaining a second context for thesecond request; identifying a second DCT rule based on the secondcontext; and serving the second request using the second DCT rule. 3.The method of claim 2, further comprising: after servicing the firstrequest and prior to receiving the second request, obtaining the secondDCT rule.
 4. The method of claim 2, further comprising: after storingthe object in a content repository and prior to receiving the firstrequest, obtaining the DCT rule.
 5. The method of claim 4, furthercomprising: after storing the object in the content repository and priorto receiving the first request changing the object type of the object toDCT.
 6. The method of claim 1, wherein the context for the first requestis based, at least in part, on an application that issued the firstrequest.
 7. The method of claim 1, wherein the context for the firstrequest is based, at least in part, on a platform from which the firstrequest was issued.
 8. The method of claim 1, wherein the context forthe first request is based, at least in part, on the object, the action,and a user associated with the request.
 9. The method of claim 1,wherein the context for the first request is based at least in part on asource content repository in which the object is currently stored and atarget content repository in which the object is to be stored.
 10. Themethod of claim 1, wherein the action is one selection from a groupconsisting of a read, write, modify, delete, and move.
 11. The method ofclaim 1, wherein the DCT rule specifies at least one selected from agroup consisting of a context definition, a metadata visibility rule,and a content visibility rule.
 12. The method of claim 10, wherein theDCT rule further specifies at least one permitted action and whereinserving the first request comprises providing the requesting entity withinformation related to the at least one permitted action.
 13. The methodof claim 1, wherein serving the first request comprises: obtainingcontent from the object; modifying the content in accordance with acontent visibility rule specified by the DCT rule to obtain modifiedcontent; and providing the modified content to the first requestingentity.
 14. The method of claim 1, wherein serving the first requestcomprises: obtaining metadata from the object; modifying the metadata inaccordance with a metadata visibility rule specified by the DCT rule toobtain modified metadata; and providing the modified metadata to thefirst requesting entity.
 15. The method of claim 1, wherein serving thefirst request comprises: obtaining content from the object; modifyingthe content in accordance with a content visibility rule specified bythe DCT rule to obtain modified content; obtaining metadata from theobject; modifying the metadata in accordance with a metadata visibilityrule specified by the DCT rule to obtain modified metadata; andproviding the modified content and the modified metadata to the firstrequesting entity.
 16. A non-transitory computer readable mediumcomprising computer readable program code, which when executed by acomputer processor enables the computer processor to perform a methodfor servicing requests, the method comprising: receiving, from a firstrequesting entity, a first request to perform an action on an object;making a first determination that an object type of the object isdynamic content type (DCT); based on the first determination, obtaininga context for the first request; identifying a DCT rule based on thecontext; and serving the first request using the DCT rule.
 17. Thenon-transitory computer readable medium of claim 16, the method furthercomprising: receiving, from a second requesting entity, a second requestto perform the action on the object; making a second determination thatthe object type of the object is DCT; based on the second determination,obtaining a second context for the second request; identifying a secondDCT rule based on the second context; and serving the second requestusing the second DCT rule.
 18. The non-transitory computer readablemedium of claim 16, wherein the action is one selection from a groupconsisting of a read, write, modify, delete, and move and wherein theDCT rule specifies at least one selected from a group consisting of acontext definition, a metadata visibility rule, and a content visibilityrule.
 19. A system, comprising: a content repository storing an object;a content management system coupled to the content repository andprogrammed to: receive, from a first requesting entity, a first requestto perform an action on the object; make a first determination that anobject type of the object is dynamic content type (DCT); base on thefirst determination, obtain a context for the first request; identify aDCT rule based on the context; and serve the first request using the DCTrule.
 20. The system of claim 19, wherein the content management systemis further programmed to: receive, from a second requesting entity, asecond request to perform the action on the object; make a seconddetermination that the object type of the object is DCT; based on thesecond determination, obtain a second context for the second request;identify a second DCT rule based on the second context; and serve thesecond request using the second DCT rule.